Choosing the right design process
In my first story ‘User Experience is …’ I promised that …
"over the course of a few stories, I’ll try and cover a few of the sciences we draw upon in our art as a creative community to create engaging experiences."
In my last story I talked around how User Experience is … user story flow to capture value and certainty within user stories. Design frameworks help us to learn, define, experiment, build, test and learn so we can create certainty, define user stories and iterate. So this time out I’m looking at design frameworks …
Choosing the right design process
On my journey to be comfortable to talk about design and do so with knowledge and insight I’ve come across many a story talking about design, tools and processes, techniques and design frameworks.
These are the questions I asked myself when I first come across them. They seemed to be regarded as the pinnacle of design practise, however in my experience have been shrouded in elitism and academia.
But there is nothing further from the truth. What I’ve come to learn is that they provide a great reference point for picking and choosing the best, next step in your own design process. Allowing you to provide more certainty for your product and engineering teams. But more than this, they do provide a great visualisation aid when mentoring people.
I’ve used design frameworks to hang conversations off when mentoring university students and those in the business, with more than a passing interest in design, to increase design maturity within the organisation. This has allowed me to provide a high level overview of all the possible steps to take, but also take a deep dive into one of the techniques that is able to help refine the design at that moment in time.
There are several design frameworks out there. So strap in and I’ll take a quick skip through 8 of the most popular and mature.
Developed by the Design Council to illustrate how every design specialism has a different approach and ways of working, but there are some commonalities to the creative process.
Adapted Design Council Double Diamond model including methods and techniques
Divided into four distinct phases; Discover, Define, Develop and Deliver, the Double Diamond is just a simple visual map of the design process.
The Double Diamond indicates that exploring possible ideas and narrowing down to the best idea happens twice. Once to confirm the problem definition and once to create the solution. One of the greatest mistakes is to omit the left-hand diamond and end up solving the wrong problem.
In order to discover which ideas are best, ideas are developed, tested and refined a number of times, with weak ideas dropped in the process.
The first quarter of the Double Diamond model covers the ‘discover’, or start of the project. This is the time to gather insights and look for inspiration.
The second quarter represents the definition stage, where you try and make sense of all the possibilities identified in the discover phase. The goal here is to frame the fundamental design challenge.
The third quarter marks a period of development where solutions or concepts are created, prototyped, tested and iterated. This process of trial and error helps to improve and refine ideas.
The final quarter of the double diamond model is the delivery stage, where the resulting project (a product, service or environment, for example) is finalised, produced and launched.
Lean UX and how to get started, UX Planet
Lean UX is focused on doing the right things for the team to achieve a desirable experience and less focused on traditional deliverables. It requires a greater level of collaboration with the entire team. The core objective is to focus on obtaining feedback as early as possible so that it can be used to make quick decisions. The nature of Agile development is to work in rapid, iterative cycles and Lean UX mimics these cycles to ensure that data generated can be used in each iteration.
Traditional projects are built on requirements and deliverables, focussing on the deliverables responding adequately to the requirements.
Lean UX instead uses problem statements which lead to assumptions and creation of hypotheses to test and learn from. It’s understood that the assumptions might not be correct and could be changed, but this quickly uses the knowledge of the team in order to explore how to solve the known problems. This test and learn approach enables the team to quickly mobilise and focus around core problems which could improve the user experience.
Scrum Framework, What is scrum?
Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum highlights the efficiency and effectiveness of work techniques, to continuously improve the product, the team, and the working environment.
Design Thinking provides a solution focussed approach to solving problems. It’s useful to tackle complex problems that aren’t well defined, by understanding human needs to re-frame the problem in a human-centric way, so that many ideas can be created to prototype and test and learn from likely solutions. There are 5 different stages involved:
The IBM Loop framework provides the foundation for delivering solutions that meet users’ expectations. To be successful, they must speak to your team’s heart as well as its head. The Loop is a continuous cycle of observing, reflecting and making:
The Design Sprint is a time boxed process for answering critical business questions through design, prototyping, and testing ideas with final users and customers, to solve design problems quickly.
Design sprint can help companies enter new markets, design new products, develop new features for millions of users, define marketing strategies, and much more. Design sprints are versatile and adaptable but here’s the basic premise:
Design Sprint process, Google Ventures
5 steps to a hypothesis driven design process, Invision
Hypothesis-driven design helps navigate through an unknown space, so you come out at the end with actionable next steps:
Jobs-to-be-Done Theory provides a framework for defining, categorizing, capturing, and organizing all your customers’ needs.
Moreover, when using this framework, a complete set of need statements can be captured in days — rather than months — and the statements themselves are valid for years — rather than quickly becoming obsolete.
Armed with knowledge of all the customers’ needs, a product team can:
Which stands for:
Ultimately this means researching, iterating, and testing, while keeping everything user centred (e.g. everything you need to do in a good design process).
What does each different framework offer the designer?
So use a design framework you’re happy with that supports you, your conversations and your work, to refine and provide more certainty for your teams.
Don’t be intimidated by it, get to know it and how it can help you, so that you can help others either in person or in your products your designing.
Try not to be a purist but be pragmatic and take the best bits that suit your situation and organisation. Being a purist often leaves you open to people questioning the value you provide instead of the getting these people to focus on the outcomes you deliver, if you’re a little more pragmatic.
But a lot of the robust work that’s done leans on choosing the right framework at the right time. But also to understand where you are, in your understanding, what remains uncertain and which method you choose in order to provide the remaining certainty needed to build out a robust, usable and intuitive design.
Well, it’s quite simple, you just need to understand what you need to know in order to progress. Other than this, it’s a case of experience and knowing the different design methods and what they can offer. So in a bid to help you out with that later piece, here’s an overview of what each method or framework offers and when it can help.
Choosing the right design process
Use a design framework that brings the team together and develops the certainty and confidence needed in order to continue sprinting and the team learning. If there is something that the team is finding challenging find the right technique to break down the challenge. Focus on the collaboration not the documentation of the technique.
Once you get familiar with different design frameworks, you’ll then be able to use the tools and techniques from each design framework in order to best support the team and the challenges it’s currently facing whether that’s because something that is complex or unknown.
All the design frameworks are roughly based around these concepts:
So as long as you’re stepping through each one of these steps, using a suitable technique to provide what the team needs in order to progress then everything is golden.
Design Thinking process: empathise, define, ideate, prototype, test
You might apply design thinking as a frame of mind throughout your design work. Design thinking is based on how to use industrial design to solve real world problems. Using these 4 fundamental methods:
Design Sprint process, Google Ventures
Use design sprints to put a structure in place when a problem is well known and understood to rapidly test and learn and accelerate the iteration of a viable solution.
“The sprint is a unique five-day process for answering crucial questions through prototyping and testing ideas with customers. It’s a greatest hits of business strategy, innovation, behavioural science, design and more — packaged into a step-by-step process that any team can use.”
Jake Knapp, author of ‘Sprint: How to solve big problems and test new ideas in just five days
As depicted in the book, sprints are organised when a product team knows there’s a problem. The group gets together to explore a possible solution, allocating each weekday for a single method:
Design thinking is the cooking class … design sprint is the recipe … doing a cooking class is great, but without a recipe, you’re going to waste a lot of time trying to figure out exactly how to make our fantastic spaghetti dish.
Jonathan Courtney, Founder of AJ&Smart
To use this food analogy from Jonathan Courtney, if you think of a solution as a dish, then you could think of design thinking of a cooking class.
This teaches the general philosophies of cooking, how flavour works, which ingredients complement each other, how to prepare specific items (chopping onions, cooking meat, making a sauce etc.).
The design sprint could be considered the recipe. It’s a method, which shows you the ingredients you’ll need, what to do, when to do it and, potentially who should do what.
Design frameworks then are all about understanding the kitchen, cooking equipment and utensils and when to use them all to create something unique.
While the list is not true for every instance of each application, here are a few distinct observations to watch for:
Most of these frameworks are linear processes and often in reality the discovery and problem definition are cyclical. Learning only increases, the longer you spend working on a product, so you’re bound to review previous thinking, decisions and approaches with the new insight in order to challenge and refinement them.
I’ve never been involved with a product that uses all of the tools and techniques. Instead we’ve cherry pick the areas where there are unknowns or uncertainty and then use the technique to provide certainty and make sensible decisions.
This is where following one design system might not be the best thing to do for your product, team or organisation. It's about a more blended approach and knowing what you need to know next to progress, to build understanding, certainty or reduce risk.
After speaking with many designers in the community, each designer has their favourite, which they’re happy and comfortable will support them, their conversations and work. They use this as a base to then embellish with other relevant techniques of parts of design systems along the way.
So my advise is try not to be a purist but be pragmatic, take the best bits that suit your situation and organisation. Being a purist often leaves you open to people questioning the value you provide instead of the getting these people to focus on the outcomes you deliver, if you’re a little more pragmatic.
It’s an agile principal but it’s relevant here. Use the tools and techniques from each design system that brings the team together and develops the certainty and confidence needed in order to continue sprinting and the team learning. If there is something that the team is finding challenging find the right technique to break down the challenge. Focus on the collaboration not the documentation of the technique.
All the design frameworks are roughly based around these concepts:
So as long as you’re stepping through each one of these steps, using a suitable technique to provide what the team needs in order to progress then everything is golden.
Continually testing and learning is key to validate you are heading in the right direction and test if your hypothesis and assumptions are correct. This allows you to create more certainly for the team at each step. And allows the team to rethink, relearn and reboot, to realign and check that the most value is being extracted from the possible solution. You won’t go too far wrong if you test early and test often, it’s a great safeguard for teams and individuals.
‘Prototype like you’re right, test like you’re wrong’
'Testing and validation is not able being right, but instead it's about being a little less wrong'
So hopefully that goes some way to dispell the myths and also allow you to work leanly and with agility to lean and test hypothesis as you go by using the right tools at the right time to build certainty in the teams you're working with.
Next up I’ll look at something that I care deeply about. Inclusive design and how every design should be accessible by all. Looking at how User Experience is … accessible design.
Originally written as part of the ‘User Experience is …’ series for UX Collective.